Description

AsyncScheduler.flush() has two bugs in its error handling that were never fixed, even though the same class of bugs were fixed in AsapScheduler and AnimationFrameScheduler via #6674 and #7444.

Bug 1: Sibling actions are killed on error

When any action errors during a flush, the error handler unsubscribes ALL remaining queued actions:

// AsyncScheduler.flush() — before this PR
if (error) {
  while ((action = actions.shift()!)) {
    action.unsubscribe();  // kills every remaining action
  }
  throw error;
}

The erroring action already unsubscribes itself in AsyncAction._execute(). The remaining actions are independent operations that should not be affected.

Bug 2: Synchronous throw tears down subscriber chains

After killing siblings, flush() throws synchronously. For QueueScheduler (delay=0), this throw propagates back through the synchronous call stack: QueueAction.schedule() → executeSchedule() → OperatorSubscriber._next catch → destination.error() — tearing down the entire subscriber pipeline.

This is the root cause of NgRx "store death": observeOn(queueScheduler) queues independent subscriber notifications in the same flush cycle. When one errors, the throw propagates through the subscriber chain and unsubscribes the entire observeOn → withLatestFrom → scan → State pipeline.

The Fix

1. Remove the blanket while (actions.shift()) { action.unsubscribe() } loop
2. Replace throw error with reportUnhandledError(error) and continue flushing

 do {
   if ((error = action.execute(action.state, action.delay))) {
-    break;
+    reportUnhandledError(error);
+    error = null;
   }
 } while ((action = actions.shift()!));
 
 this._active = false;
-
-if (error) {
-  while ((action = actions.shift()!)) {
-    action.unsubscribe();
-  }
-  throw error;
-}

Errors surface asynchronously via config.onUnhandledError or setTimeout — consistent with how ConsumerObserver.next already handles subscriber errors in RxJS. The erroring action still self-cleans via _execute(). Remaining actions execute in the same flush.

Background

• fix: scheduler unsubscription scenarios #6674 fixed this class of bug for AsapScheduler and AnimationFrameScheduler using flushId scoping — but AsyncScheduler was never given the same treatment
• fix(animationFrameScheduler): some tasks are never flushed and sometimes it breaks completely #7444 further refined the AnimationFrameScheduler fix
• QueueScheduler extends AsyncScheduler without overriding flush(), so it inherits the unfixed error handling
• Related issues: AsapScheduler race condition w/ nested schedules (Cannot read properties of undefined (reading 'execute')) #6672, Scheduler.flush throws unclear error when actions is empty (cannot read property 'execute' of undefined) #4690, TypeError: undefined is not an object (evaluating 'e.execute') in AsapScheduler.flush #2697

Test plan

• Errors are reported via config.onUnhandledError, not thrown synchronously
• Sibling actions are not unsubscribed when one errors
• Sibling actions execute in the same flush (no deferred execution)
• NgRx pattern: observeOn(queueScheduler) with two subscribers — one throws, both subscriptions survive, subsequent emissions still work
• Scheduler is reusable after an error
• All 123 scheduler tests pass
• Full suite: 3243/3245 pass (2 pre-existing: ajax JSON format + WebSocket constructor on modern Node.js)

cc @benlesh @cartant @pmoleri @trxcllnt

Made with Cursor